Method and apparatus for exchanging electronic business cards in a point-to-point or a multi-point personal computer conference

ABSTRACT

The conference manager of a general purpose personal conference application is enhanced, including a request management and a send/receive function for exchanging &#34;business cards&#34; electronically using a two-phase approach, a request phase and an answer phase. While request for another participant is automatic responsive to a connect/joint event, answering a request is conditionally depending on whether the receiving system is &#34;in conference&#34;. The external manifestation of an electronic &#34;business card&#34; (bizcard) is a visual presentation of information commonly found on physical business cards in a format that resembles a physical business card. Preferably, the visual presentation also includes a picture of the person named. Internally, the information including the data necessary to render the picture are maintained in data structures.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates to the field of personal computer (PC)conferencing. More specifically, the present invention relates to theexchange of electronic business cards among conference participants of apoint-to-point or a multi-point computer conference.

2. Background Information

As advances in telecommunication and computing technology continue tobring forth more powerful PC conferencing systems, both users and systemintegrators desire closer modeling of participant behaviors oftraditional face-to-face conferences in PC conferences. One particularbehavior of interest is the practice of conference participantsexchanging business cards in face-to-face conferences. The businesscards not only serve as vehicles of introduction, they also serve asinformation sources. It is not uncommon for conference participants tosave the exchanged business cards and refer to them later on.

The conference participants may refer to the saved business cards for avariety of reasons. Sometimes, the conference participants may bereferring to the saved business cards simply to remind them of thepersons they met, including the fellow participant's affiliations,titles, etc. Other times, the conference participants may be referringto the saved business cards to figure out the roles, the interests, etc.of the fellow participants in attending particular conferences oradvocating particular points of views, through the affiliations, titlesetc. information. Yet other times, the conference participants may bereferring to the saved business cards as a resource for someone to whomthey themselves can turn or refer colleagues, clients etc. to consult oncertain subject matters.

In sum, notwithstanding the limited amount of information typicallycontained in a business card, its utility is amazingly broad. In fact,it is a common practice for professionals in a variety of disciplines toroutinely enter the information in business cards into their addressdatabases for subsequent retrieval for the purposes described earlier,and/or for mailing of announcements, seasonal greeting cards etc.

Thus, it is desirable to be able to model business card exchanges forconference participants of a PC conference. It is further desirable tobe able to capture the information in the exchanged "business cards" forsubsequent retrieval. Copending U.S. patent application, Ser. No.08/444,020, entitled Method And Apparatus For Exchanging ElectronicBusiness Cards In A Point-to-Point or Multi-Point Personal ComputerConference PENDING discloses a method and apparatus that achieve theseand other desirable results. The disclosed method and apparatus teachthe employment and exchange of a data structure containing informationthat are commonly found in business cards, and the rendering of theinformation in a business card like format. These data structures arereferred to as "bizcards". Furthermore, the disclosed method andapparatus teach the automatic exchange of these bizcards at the timeparticipants join a conference.

The automatic exchange works well for PC conferences wherein therelative performance of the conferencing PCs are substantially the same.For these conferences, all participating PCs will complete theirconnection processing at relatively the same time. Thus, it is unlikelyfor a PC to receive one of these bizcards and not knowing what to dowith it, because the connection processing of the particular PC has notbeen completed.

However, as PC conferencing become more widely accepted and used by moreusers, and not "exclusively" practiced by the most sophisticated usersonly, it is expected the relative performance differences amongpotential conferencing PCs will grow wider. Thus, the odds of a PCreceiving a bizcard and not knowing what to do with it, because it hasnot completed its connection processing will increase, resulting in lossof data and less reliable modeling of the business card exchangebehavior in a face-to-face conference. Thus, it is desirable to have analternative approach to exchanging bizcards among the conferenceparticipants of a PC conference. As will be described in more detailbelow, the method and apparatus of the present invention achieves theseand other desirable results.

SUMMARY OF THE INVENTION

The conference manager of a general purpose personal conference (GPPC)application is enhanced, including the provision of first requestmanagement and send/receive functions for exchanging bizcards with otherconference participants of a computer conference using a two-phaseapproach, thereby allowing the business card exchange behavior ofconference participants of face-to-face conferences to be modeled morereliably even among PCs with wider differences in processing power.

The external manifestation of a bizcard is a visual presentation ofinformation commonly found on physical business cards in a format thatresembles a physical business card. Preferably, the visual presentationalso includes a picture of the person named. Internally, the informationincluding the data necessary to render the picture are maintained indata structures, thereby allowing the information captured to besearchable for subsequent retrieval.

More specifically, the conference manager is enhanced to automaticallyrequest a connecting or a joining participant's bizcard, responsive toeach participant connecting or joining event. A request managementfunction is used to manage bizcard requests received from otherconference participants. All requests received prior to the GPPCapplication entering an "in conference" state are queued, and allpreviously queued requests are processed when the GPPC applicationenters the "in conference" state. A send/receive function is used tosend and receive bizcards between the user and other conferenceparticipants, in cooperation with the request management function.

BRIEF DESCRIPTION OF DRAWINGS

The present invention will be described by way of exemplary embodiments,but not limitations, illustrated in the accompanying drawings in whichlike references denote similar elements, and in which:

FIG. 1a & 1b illustrate a typical point-to-point and a typicalmultipoint PC conference incorporating the teachings of the presentinvention;

FIG. 2 illustrates one embodiment of a GPPC application incorporated ineach of the PC's of FIG. 1a & 1b, including the request management andsend/receive functions employed by the conference manager forimplementing the two phase approach to exchanging bizcards of thepresent invention;

FIGS. 3a & 3b illustrate the external manifestation and internalrepresentation of one embodiment of bizcard;

FIGS. 4a-4b illustrate one embodiment of the end user interfacesemployed by the conference manager of FIG. 2 for rendering bizcardsduring operation;

FIG. 5 illustrates one embodiment of the end user interfaces employed bythe address service of FIG. 2 for retrieving and browsing saved bizcardsduring operation; and

FIGS. 6a-6d illustrate the operational flow of one embodiment of thebizcard request management and send/receive functions of the conferencemanager of FIG. 2.

DETAILED DESCRIPTION OF THE INVENTION

In the following description, for purposes of explanation, specificnumbers, materials and configurations are set forth in order to providea thorough understanding of the present invention. However, it will beapparent to one skilled in the art that the present invention may bepracticed without the specific details. In other instances, well knownfeatures are omitted or simplified in order not to obscure the presentinvention.

Referring now to FIG. 1a & 1b, two exemplary networks of PC conferencingsystems incorporated with the teachings of the present invention areillustrated. FIG. 1a illustrates an exemplary point-to-point PCconferencing system 10, whereas FIG. 1b illustrates an exemplarymulti-point PC conferencing system 20. Point-to-point PC conferencingsystem 10 comprises PC A & B 12a and 12b connected to each over viaPOTS, ISDN or LAN 14, whereas multi-point PC conferencing system 20comprises PC C-G 12c-12g and multi-point control unit (MCU) 16 connectedto each other via ISDN 14. PC A 12a and PC B 12b are joined together inconference when one of the two PC's 12a or 12b call the other. PC C-G12c-12g are joined together in conference via MCU 16 when PC's 12c-12gindividually call MCU 16.

While for ease of explanation, exemplary multi-point PC conferencingsystem 20 is illustrated with all PC C-G 12c-12g joined in conferencevia one MCU 16, based on the description to follow, it will beappreciated that the present invention may be practiced with multi-pointPC conferencing system employing one or more MCU's 16. Furthermore, MCU16 may be managing multiple multi-point PC conferences.

PC A-G 12a-12g and MCU 16 are all equipped with relative highperformance processors having sufficient computing power for processingdigitized audio and video data in real time. However, under the presentinvention, PC A-G 12a-12g may be equipped with processors from differentperformance classes having greater differences in computing power.Additionally, each of PC A-G 12a-12g and MCU 16 is also equipped withcommunication interface(s) and storage medium. PC A-G 12a-12g arefurther equipped with audio/video subsystems. Communication interfaces,storage medium, and audio/video subsystems may be implemented with anynumber of such elements well known in the art.

MCU 16 is equipped with multi-point control software having capabilitiessimilar to MCUs employed in AT&T's WorldWorx.SM. service provided byAT&T of New Jersey. PC A-G 12a-12g are all equipped with identicalgeneral purpose personal conference (GPPC) applications incorporatedwith teachings of the present invention. Each GPPC application includesbase conferencing functions similar to those offered by the ProShare™Personal Conferencing System manufactured by the assignee of the presentinvention. Each GPPC application also includes extended conferencingfunctions for setting up, exchanging, saving, retrieving, and browsingbizcards, which will be described in more detail below. For a moredetail description of AT&T's WorldWorx.SM. service and ProShare™, referto their respective product literature's.

FIG. 2 illustrates one embodiment of a GPPC application incorporatedwith the teachings of the present invention in further detail. As shown,for this embodiment, GPPC application 22 comprises user interface 24,conference manager 26, profile data 28 and address services 30.Furthermore, GPPC application 22 comprises transport independentservices 34, extended A/V services 36, and "integrated" data and videointerfaces 32a and 32b to these services 34 and 36. In the presentlypreferred embodiment, GPPC application 22 is implemented in anobject-oriented manner using the programming language C++.

User interface 24 provides display windows with menus, buttons etc. forinteracting with a user. In particular, in accordance to the presentinvention, user interface 24 includes enhancements for facilitating setup, exchange, retrieval, browse and re-send of bizcards. Conferencemanager 26 manages personal conferences including the conferencingapplications. In particular, conference manager 26 maintains aconference state denoting whether the PC conferencing system is "inconference" or not. Furthermore, conference manager 26 also includes acreate/edit function for creating and editing a user's bizcard.Conference manager 26 also includes a request management and asend/receive function for implementing a two-phase approach toexchanging and saving bizcards between the user and other conferenceparticipants, in accordance to the present invention. Associated withthe request management function is a request queue. Profile 28 storesvarious user preferences. In particular, profile 28 includes the user'sbizcard and the user's preference on whether a received bizcard is to bedisplayed automatically. Address services 30 provide services related tomanaging connection addresses for conference participants. Inparticular, address services 30 include services for retrieving andbrowsing saved bizcards. These functions and services will be describedin further detail below.

Transport independent services 34 provide connection services onmultiple transport media and multiple connections. A/V services 36provide sampling, digitization, compression/decompression of audiosignals exchanged, as well as capture and playback services for videostreams including interfacing with the proper CODEC to compress anddecompress the video signals. Integrated data and video interfaces 32aand 32b provide abstraction of these transport and A/V services,enabling the serviced application to perform call management, dataand/or file channel management, and A/V streams management. In oneembodiment, integrated data interface 32a supports ITU's T120 protocolfor data conferencing, whereas integrated video interface 32b supportsITU's H.320 protocol for video conferencing. These and other relatedservices are known in the art, and therefore will not be described infurther detail.

FIGS. 3a & 3b illustrate the external manifestation and internalrepresentation of a bizcard. As shown in FIG. 3a, the externalmanifestation is a visual representation 38 of information commonlyfound on physical business cards in a format that resembles a physicalbusiness card. These information include name 39a, title 39b, company39c, division 39d, address 39e, numbers 39f etc. Preferably, numbers 39finclude all personal conferencing phone numbers/network addresses, inaddition to conventional voice and facsimile phone numbers, and numbers39f are scrollable, e.g. using up and down arrows 39h. Furthermore, thevisual presentation 38 includes a picture 39g of the person named.Alternatively, a company logo may be included. As shown in FIG. 3b,internally, the information including the data necessary to render thepicture 41g are maintained in data structures 40. Data structures 40include data elements 41a-41g necessary to store the capturedinformation. Data necessary to render the picture 41g may be stored inany number of graphics format well known in the art. The create/editfunction of conference manager 26 for creating and editing user'sbizcard 38, including its operational flow and end-user interfaces maybe implemented in a variety of manners, including but not limited to theembodiment disclosed in the above identified co-pending patentapplication, which is hereby fully incorporated by reference.

FIGS. 4a-4b illustrate one embodiment of the user interfaces employedfor rendering bizcards. In particular, FIG. 4a illustrates the displayof one conference participant's bizcard (Salvador) 38f at anotherconference participant's conference session window (Elliott) 50, whenthe two participants first joined together in conference. FIG. 4billustrates the display of a "new" conference participant's bizcard(Skarbo) 38g at one of the existing conference participant's conferencesession window (Elliott) 50, when the "new" conference participant isjoining a conference in progress (between Elliott and Salvador). Asdescribed earlier, bizcards 38f and 38g may be displayed automaticallyupon receipt, or bizcards 38f and 38g may be displayed upon request,using exemplary command button "?" 54, depending on the conferenceparticipant's preference setting. Preferably, notwithstanding anautomatic display preference setting, exemplary command button "?" 54may also be used to re-display the bizcard 38f or 38g of one of theconference participants, whenever the user is interested in doing soduring the conference. The request management and send/receive functionsof conference manager 26 for exchanging, rendering and saving bizcards38 in accordance to the two-phase approach of the present invention willbe described in more detail below.

FIG. 5 illustrates the user interface employed by the functionsincorporated in address services 30 for retrieval and browsing of savedbizcards. As shown, the bizcard function of address service 30 includesan address book/addressee selection window 72. Address book/addresseeselection window 72 includes an addressee display area 75 where the usercan make his/her addressee selection. As described earlier, the selectedaddressee is highlighted, the selected addressee's saved bizcard 38h (ifit exists) is displayed. Additionally, address book/addressee selectionwindow 72 also includes a first input area 73 for locating an addressee,and a second input area 74 for switching address book. The bizcardfunction of address service 30 for retrieving and browsing savedbizcards 38h may be implemented in a variety of manners, including butnot limited to the embodiment disclosed in the above identified andincorporated by reference co-pending patent application.

Referring now to FIGS. 6a-6d, the operational flow of one embodiment ofthe request management and send/receive functions of conference manger26 is shown. As shown in FIG. 6a, in response to a conferenceparticipant "connecting" or "joining" event, in addition to the normalconnect/join processing, conference manager 26 issues a request to theconnecting/joining conference participant for his/her bizcard, step 102.As shown in FIG. 6b, in response to a bizcard request event, the requestmanagement function of conference manager 26 first checks the state ofGPPC application 22 and determines whether the user is in conference,step 104. If the user is in conference, then the send/receive functionis invoked to send the user's bizcard 38 to the requester, step 106.Otherwise, the request management function queues the bizcard request inits request queue, step 108. As will be appreciated by those skilled inthe art, in lieu of an exclusive bizcard request queue, a multi-purposerequest queue wherein the nature of a request is identifiable may alsobe used.

As shown in FIG. 6c, in response to a connection processing completeevent, i.e. the GPPC application is in a state of "in conference", therequest management function of conference manager 26 checks the requestqueue to determine whether there are any pending bizcard requests, step110. If there are no pending request, the request management functiontakes no further action. On the other hand, if there is at least onepending bizcard request, for each pending bizcard request, thesend/receive function is invoked to send the user's bizcard 38 to therequester, step 114. The process is repeated until all bizcard requestshave been answered, steps 110 and 114. As shown in FIG. 6d, in responsea bizcard receipt event, the send/receive function of conference manager26 first checks the user's display preference setting, step 116. If thepreference setting is set to "auto display", the send/receive functioncauses the received bizcard 38 to be rendered, step 118. Regardless ofthe preference setting, preferably, the send/receive function also savesthe received bizcard for subsequent retrieval, if the user does notalready has a copy of the received bizcard, step 120. Furthermore, the"saving" into a permanent storage is preferably deferred untilconference termination. By deferring saving into permanent storage, moreCPU cycles would be available for performing real time processing ofaudio and video data. Moreover, it is more efficient for a multi-pointconference to save all received bizcards 38 at the same time, as opposedto saving the bizcards 38 as they are received, since presumably eachsaving will require file opening and closing.

Lastly, as will be appreciated by those skilled in the art, thetwo-phased approach to exchanging bizcards among conference participantsof the present invention described above is transparent to theconference participants. In other words, from the conferenceparticipants'perspectives, the behavior for exchanging business cards inface-to-face conferences is modeled in like manner, except for the factthat for the behavior is modeled more reliably notwithstanding widerperformance differences among the participant PCs.

Thus, a method and apparatus for exchanging electronic business cardexchanges in a point-to-point or a multi-point personal computerconference has been described. While the method and apparatus of thepresent invention has been described in terms of the above illustratedembodiments, those skilled in the art will recognize that the inventionis not limited to the embodiments described. The present invention canbe practiced with modification and alteration within the spirit andscope of the appended claims. The description is thus to be regarded asillustrative instead of restrictive on the present invention.

What is claimed is:
 1. A personal computer (PC) conferencing systemcomprising a general purpose personal conferencing (GPPC) applicationhaving a conference manager that automatically requests a business carddata structure from a connecting or a joining conference participantresponsive to a connect or a join event denoting the connecting orjoining of another PC conferencing system to the PC conferencing systemin a point-to-point computer conference or the joining of another PCconferencing system to a multi-point computer conference, of which thePC conferencing system is a current participant respectively,wherein theconference manager further includes a first function for managingbusiness card data structure requests from other PC conferencingsystems, and a second function for sending and receiving business carddata structures between the PC conferencing system and other PCconferencing systems in coordination with the first function, and, thebusiness card data structure includes information commonly found inbusiness cards and, the information are rendered on each of the PCconferencing systems in a format that resembles a business card.
 2. ThePC conferencing system as set forth in claim 1, wherein responsive toeach business card data structure request, the first function eitherqueues the business card data structure request if the PC conferencingsystem is not in conference, or in cooperation with the second function,cause the requested business card data structure to be sent to therequesting PC conferencing system if the PC conferencing system is inconference.
 3. The PC conferencing system as set forth in claim 2,wherein responsive to each completion of connection processing by the PCconferencing system, the first function checks to determine whetherthere are any pending business card data structure requests, and ifthere is at least one pending business card data structure request, thefirst function in cooperation with the second function cause the PCconferencing system's business card data structure to be sent to each ofthe other PC conferencing systems whose business card data structurerequests were pending.
 4. A point-to-point personal conferencing systemcomprising a first and a second PC conferencing system coupled to eachother, the first and second PC conference systems having a first and asecond general purpose personal conference (GPPC) applicationrespectively,wherein each GPPC application includes a conference managerthat automatically requests a business card data structure from theother PC conferencing system whenever the other PC conferencing systemrequest to connect to the PC conferencing system for a point-to-pointcomputer conference, each of the conference managers further includes afirst function for managing business card data structure requests fromother PC conferencing systems, and a second function for sending andreceiving business card data structures with the other PC conferencingsystem in coordination with the first function, and, the business carddata structure includes information commonly found in business cardsand, the information are rendered on each of the PC conferencing systemsin a format that resembles a business card.
 5. The point-to-pointconferencing system as set forth in claim 4, wherein responsive to eachbusiness card data structure request received by one of the PCconferencing systems, the corresponding first function either queues thebusiness card data structure request if the receiving PC conferencingsystem is not in conference, or in cooperation with the second function,cause the requested business card data structure to be sent to therequesting PC conferencing system if the receiving PC conferencingsystem is in conference.
 6. The point-to-point personal conferencingsystem as set forth in claim 5, wherein responsive to each completion ofconnection processing of one of the PC conferencing systems, thecorresponding first functions checks to determine whether there is abusiness card data structure request from the other PC conferencingsystem that is pending, and if there is a business card data structurerequest from the other PC conferencing system pending, the firstfunction in cooperation with the second function cause the PCconferencing system's business card data structure to be sent to theother PC conferencing system.
 7. A multi-point personal conferencingsystem comprising a first, a second and a third PC conferencing system,and a multi-point control unit (MCU), the first, second and third PCconferencing systems being coupled to the MCU and having a first, asecond and a third general purpose personal conference (GPPC)application respectively,wherein each of the GPPC applications includesa conference manager that automatically requests a business card datastructure from a joining conference participant responsive to a joinevent denoting the joining of one of the other PC conferencing systemsto the PC conferencing system in a multi-point computer conference, eachof the conference managers further includes a first function formanaging business card data structure requests from the other PCconferencing systems, and a second function for sending and receivingbusiness card data structures between the PC conferencing system and theother PC conferencing systems in coordination with the first function,and the business card data structure includes information commonly foundin business cards and, the information are rendered on each of the PCconferencing systems in a format that resembles a business card.
 8. Themulti-point conferencing system as set forth in claim 7, whereinresponsive to each business card data structure request received by oneof the PC conferencing systems, the corresponding first function eitherqueues the business card data structure request if the receiving PCconferencing system is not in conference, or in cooperation with thesecond function, cause the requested business card data structure to besent to the requesting PC conferencing system if the receiving PCconferencing system is in conference.
 9. The multi-point personalconferencing system as set forth in claim 8, wherein responsive to eachcompletion of connection processing of one of the PC conferencingsystems, the corresponding first functions checks to determine whetherthere are pending business card data structure requests from the otherPC conferencing systems, and if there is at least one business card datastructure request from one of the other PC conferencing systems pending,the first function in cooperation with the second function cause the PCconferencing system's business card data structure to be sent to each ofthe PC conferencing systems whose request for the PC conferencingsystem's business card data structure is pending.
 10. A storage mediumcomprising a general purpose personal conferencing (GPPC) application tobe installed on a personal computer (PC) conferencing system, the GPPCapplication having a conference manager that automatically requests abusiness card data structure from a connecting or a joining conferenceparticipant responsive to a connect or a join event denoting theconnecting or joining of another PC conferencing system to the PCconferencing system in a point-to-point computer conference or thejoining of another PC conferencing system to a multi-point computerconference, of which the PC conferencing system is a current participantrespectively, during operationwherein the conference manager furtherincludes a first function for managing business card data structurerequests from other PC conferencing systems, and a second function forsending and receiving business card data structures between the PCconferencing system and other PC conferencing systems in coordinationwith the first function, and, the business card data structure includesinformation commonly found in business cards and, the information arerendered on each of the PC conferencing systems in a format thatresembles a business card.
 11. The storage medium as set forth in claim10, wherein during operation, responsive to each business card datastructure request, the first function either queues the business carddata structure request if the PC conferencing system is not inconference, or in cooperation with the second function, cause therequested business card data structure to be sent to the requesting PCconferencing system if the PC conferencing system is in conference. 12.The storage medium as set forth in claim 10, wherein during operation,responsive to each completion of connection processing by the PCconferencing system, the first function checks to determine whetherthere are any pending business card data structure requests, and ifthere is at least one pending business card data structure request, thefirst function in cooperation with the second function cause the PCconferencing system's business card data structure to be sent to each ofthe other PC conferencing systems whose business card data structurerequests were pending.
 13. In a personal computer (PC) conferencingsystem, a method for exchanging electronic business cards with anotherPC conferencing system, the method comprising the steps of:a)automatically requesting a first business card data structure from theother PC conferencing system responsive to a connecting or joining eventdenoting the other PC conferencing system's connecting/joining the PCconferencing system in a computer conference, where the first businesscard data structure is to contain common business card information abouta first user of the other PC conferencing system, and the informationwhen received by the PC conferencing system are to be rendered on thereceiving PC conferencing system in a format that resembles a businesscard; and b) conditionally answering a request for a second businesscard structure from the other PC conferencing system, depending on aconferencing state of the PC conferencing system, where the secondbusiness card data structure is to contain common business cardinformation about a second user of the PC conferencing system, and theinformation when received by the other PC conferencing system are to berendered on the other PC conferencing system in a format that resemblesa business card.
 14. The method as set forth in claim 13, whereinstep(b) comprises queuing the other PC conferencing system's request if theconference state of the PC conferencing system denotes the PCconferencing system as not in conference; and step (b) comprises sendingthe second business card data structure to the other PC conferencingsystem if the conference state of the PC conferencing system denotes thePC conferencing system as in conference.
 15. The method as set forth inclaim 14, wherein the method further comprises step (c) responsive toeach completion of connection processing by the PC conferencing system,checking to determine whether there are any queued pending requests forthe second business card data structure, and if there is at least onequeued pending business card data structure request, answering eachqueued pending request.